home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000481_news@columbia.edu _Fri Feb 9 10:29:56 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id KAA24609 for <kermit.misc@watsun>; Fri, 9 Feb 1996 10:29:54 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id KAA21585 for kermit.misc@watsun; Fri, 9 Feb 1996 10:29:48 -0500 (EST)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: bugs in Ckermit and Mskermit vt100 mode
  8. Date: 9 Feb 1996 15:29:30 GMT
  9. Organization: Columbia University
  10. Lines: 66
  11. Message-ID: <4ffp8q$l2c@apakabar.cc.columbia.edu>
  12. References: <4fe3po$1gr@bignews.shef.ac.uk>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <4fe3po$1gr@bignews.shef.ac.uk>,
  16. Earl H. Kinmonth <cck@kuso.shef.ac.uk> wrote:
  17. : I have observed the following unfriendly behavior in vt100 mode 
  18. : with Ckermit and Mskermit:
  19. : 
  20. : 1) With Ckermit for OS2 running under OS2 Windows 3.0 Japanese,
  21. : garbage (control characters?) in English language posts will
  22. : cause Ckermit to switch to a mode in which everything on screen
  23. : appears in the Japanese katakana font although the source text is
  24. : actually ascii.  This is purely an internal Ckermit problem.
  25. : Using ALT+X to go to the command prompt gives a standard English
  26. : display.
  27. : 
  28. : So far I've found nothing other than restarting Ckermit that will
  29. : fix this situation.
  30. : 
  31. If you could send us a session log that demonstrates the problem,
  32. along with the relevant C-Kermit configuration (particularly the
  33. SHOW TERMINAL display), we could give a specific diagnosis.
  34. However, it will probably not turn out to be a bug.  The
  35. terminal-to-host connection uses a certain presentation protocol,
  36. whose details depend upon the terminal type and other factors, but
  37. which works by mixing control information with real data.  Control
  38. information is commonly called an "escape sequence".  We are all
  39. familiar with escape sequences that position the cursor on the
  40. screen, clear the screen, and so on.
  41.  
  42. There are also escape sequences that change the character set.  In
  43. the VT220 and above series of terminals, these sequences are as spelled
  44. out by ISO standards 4873 and 2022, and the International Register
  45. of Character Sets.
  46.  
  47. It is intrinsic to the very design of terminal-to-host protocols that
  48. "garbage" can take the same form as a valid escape sequence.  The
  49. terminal has no way of telling the difference.  In your case, however,
  50. I suspect that we are not seeing garbage at all, but -- since I take
  51. it you are reading a Japanese newsgroup -- the text of the posting
  52. actually contains a "switch-to-Kanji" (or Katakana, etc) sequence,
  53. perhaps an improper one generated by the poster's news software.
  54.  
  55. But since OS/2 C-Kermit does not yet support Japanese terminal
  56. emulation, as MS-DOS Kermit 3.14 does, the Kanji comes out wrong.
  57.  
  58. In any case, should your C-Kermit screen switch into Kanji or any
  59. other undesired character set because of garbage or any other
  60. reason, you should be able to switch it back with the Reset button,
  61. Alt-R, verb \Kreset.  Failing that (it shouldn't fail), you can
  62. also escape back to the prompt (Alt-X) and give the appropriate SET
  63. TERMINAL CHARACTER-SET commands.
  64.  
  65. : 2) With MsKermit 3.14 for DOS with input echo on in an automated
  66. : login sequence, the vt100 initialization string returned by tset
  67. : (?) will result in the screen being switched to 40 column mode.
  68. : This happens with the termcap/terminfo supplied with SCO UNIX ODT
  69. : 3.0.  This does <not> happen for logins done by hand.  The
  70. : problem appears only with <script> driven logins.
  71. : 
  72. : Running mode bw80 will reset the screen to the proper display.
  73. : 
  74. Right.  This is a well-known problem, documented for years in the
  75. "beware file".  Solution: either don't SET INPUT ECHO ON during logins,
  76. or else don't run ANSI.SYS.  (The problem is that an escape sequence
  77. sent by the UNIX system is interpreted as "switch to 40 column
  78. mode" by ANSI.SYS.  It's not a Kermit problem.)
  79.  
  80. - Frank